Upgrade to dbus-rs 0.9.12 - #47

Verified on real hardware (Arch-based CachyOS, rtkit 0.14, KDE Plasma, rustc 1.97.1): this PR behaves identically to master on the RtKit path.

The local failures look environmental rather than dbus-related:

• Without rtkit installed, every dbus-path test panics — the graceful skip-guard only exists for the non-dbus build.
• With rtkit, it_works_in_different_threads spawns 32 threads doing ~6 promotions each, which trips rtkit-daemon's burst rate limiting ("Device or resource busy") — and the throttle window then poisons any test that runs shortly after, so full cargo test runs produce cascading order-dependent failures even on master. Running tests individually with ~45s spacing is deterministic.

So: no regression attributable to the dbus-rs 0.9.12 upgrade. Follow-up ideas: a dbus-build skip-guard mirroring the non-dbus one, and capping the stress test's thread count below rtkit's burst limit.

Fwiw only test_linux_api passes on Bazzite.

That matches the request-budget arithmetic: rtkit-daemon grants 25 requests per 20s window per user, master's suite issues 168 by construction, and test_linux_api only needs one — which is why it's the survivor. #48 restructures the suite to a measured 16 requests so a cold cargo test passes deterministically. If you get a chance, could you check whether that branch passes fully on Bazzite?